ANSI/AAMI SW96:2023, “Standard for medical device security—Security risk management for device Manufacturers” has been recognized by FDA as a recommended standard for security risk management. FDA has stated that the standard “provides direction to sponsors on how to consider and address cybersecurity risks in device design and development.”¹

Note: In this article, security and cybersecurity are meant to be interchangeable terms as defined in ANSI/AAMI SW96:2023.²

At a high level, ANSI/AAMI SW96:2023 defines the security risk management process as follows:

This process is well defined in ANSI/AAMI SW96:2023 in terms of “what” should be done However, for those new to the standard (and security risk management in general), additional guidance on “how” to execute the process may be needed. This article is meant to help fill that gap by providing guidance and tips for how to best identify and document security risks and related controls

Preparatory Work

Before starting to evaluate security risks and controls, stakeholders in the security risk management process should agree on a format for documenting this information (referred throughout this document as the Security Risk Assessment). A table format in a spreadsheet tool is recommended as this allows for filters and look-up functions to be applied to assist with the review and creation of content as needed. An example of typical column headings in the Security Risk Assessment is shown below.

Table 1 – Example Columns in a Security Risk Assessment

ID #

Asset

Threat

Attack Vector

Impact & Severity

Pre-Exploitability

Pre-Risk

Controls

Post-Exploitability

Post-Risk

After the format for the Security Risk Assessment is agreed upon, the current security risks and controls for similar products (both internal and competitive products) should be understood. The following aspects should be considered for similar products:

• The communication interfaces that are present.
• The types of security features that are implemented (and not implemented).
• Any known / published security vulnerabilities or issues.

The interfaces, security features, and known vulnerabilities will help identify potential security risks and controls in the security risk assessment. Good sources for this information include:

• Publicly available product information, including instructional videos and user manuals.
• News articles (including coverage of lawsuits) and recall information published by FDA.
• Vulnerabilities in the National Vulnerability Database (NVD) available on the National Institute of Standards and Technology (NIST) website.

Guidance and Tips for Content

There are different methods that can be used to organize the security risk assessment. The easiest method to demonstrate completeness of the assessment is to organize by assets. Assets should be identified in a security architecture document as elements of the product that have value to the user, patient, and business that are relevant to security. Typically, assets will include:

• The product’s clinical value in terms of proper operation and availability.
• Data stored on the product, including therapy information, Protected Health Information (PHI), and configuration data.
• Data communicated by the product.
• Software / firmware installed on the product.

Assets should be identified to a product decomposition level that makes sense. For example, for a product with a dual processor architecture both with separate software, both pieces of software may be identified as assets. This is especially true if the pieces of software have different risk levels in the product or different update methods. Data should be typically defined at the file/ container level

Including each named asset in the security risk assessment and organizing the assessment by asset allows an easy check to ensure that all assets have been included. This can be simply performed by ensuring that all assets in the security architecture document are included. If some assets are overlooked, critical security issues may not be analyzed and controlled.

After the assets are identified, the next step is to systematically analyze and identify different security threats with respect to each asset. For the threat analysis, using the STRIDE model (an acronym named from the various threat types) can be very useful, as its use helps ensure a comprehensive list of possible threats is identified and analyzed STRIDE categorizes threats as follows:

Table 2 – STRIDE Definitions³

Threat	Threat Definition	Desired property
Spoofing	Pretending to be something or someone other than yourself (e.g. using another user’s authentication information, such as username and password).	Authenticity
Tampering	Modifying data while stored (temporary or persistent) or while being transferred.	Integrity
Repudiation	Removing the ability to track actions or operations.	Identifiable / Traceable
Information Disclosure	Obtaining or exposing information without proper authorization.	Confidentiality
Denial of Service	Blocking access or service, usually by exhausting resources or overloading a communication interface.	Availability
Elevation of Privilege	Allowing someone to perform an action or access data without proper authorization rights.	Authorization

For each asset, consider each of the STRIDE threat types by asking the question “Could an attacker use this threat type to impact this asset if controls are not in place?”. If the answer is “Yes” update the security risk assessment to include the specific threat If the answer is “No” provide rationale in the assessment

FDA guidance states “cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling.”⁴ This guidance also states “security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system.”⁵

Exploitability can be applied by simply assuming that the attack will occur regardless of factors such as motivation of the attacker or value of the asset. An exploitability scale should then be applied to rank the ease with which an attack can be used to exploit a vulnerability to impact an asset. The Common Vulnerability Scoring System (CVSS) breaks exploitability into five different factors: Attack Vector, Attack Complexity, Attack Requirements, Privileges Required, and User Interaction.⁶ However, it is not practical to score each line in the security risk assessment with each of these factors. Therefore, a simplified scale as shown below is recommended.

Table 3 – Example Exploitability Scale

Exploitability Level	Description
Very Easy	Anyone (even those with no technical knowledge) could exploit the vulnerability with very little effort Example: Attacker accesses a webpage that does not automatically logout a user after a timeout period and views patient data.
Easy	Anyone with basic computer skills could exploit the vulnerability with little effort Example: Attacker connects to the hospital network and copies uncontrolled data.
Average	Anyone with more advanced computer skills and/or access to special tools or information could exploit the vulnerability Example: Attacker uses a publicly available tool to capture and decode Bluetooth communication and then sends commands to a device.
Difficult	Requires high technical ability / expertise to find and exploit the vulnerability Example: Attacker downloads firmware from a device, reverse engineers the code and makes modifications, then distributes the firmware back to the device.
Near Impossible	Special knowledge or highly restricted access would be required to circumvent security controls Example: Attacker decrypts data by obtaining access to an encryption key stored in a highly secured area.

Once a viable security threat is identified and the exploitability is estimated, the next step is determining the potential impact of that threat. The impact should be determined first based on the potential effect on the clinical use of the product. For example, assume an infusion pump can accept a new configuration file with default infusion program values over a Wi-Fi connection. If the configuration data is not encrypted, an attacker could capture the data and make modifications to the configuration file transmitted. This threat could potentially lead to over-delivery of medication to the patient if default programming values or limits are modified. This should then be identified as a high-severity threat

When threats with clinical impact are identified, the severity should be consistent with the product risk assessment. The easiest way to ensure consistency is to use a common severity scale between the product risk assessment and the security risk assessment for threats that have clinical impact.

Some threats may not impact patient safety but may significantly impact the business. Examples include the theft of patient information (HIPPA violation), theft of proprietary information, or downtime of the system (causing customer dissatisfaction). These threats need to be captured in the security risk assessment but should be clearly differentiated from those that can lead to patient harm.

Each security threat with potential safety impact should have one or more security controls identified. High risk threats for business-only impact should have controls defined as well. If controls cannot be identified, rationale should be provided. The scope and effectiveness of control should align with a security risk scale; higher risks need more assurance that the attack can be prevented or mitigated. The information previously collected for similar products can be very useful when considering the type and scope of controls needed.

The security risk scale should be based on the exploitability of the attack / vulnerability and the severity of the end effect. An example of such a scale is provided below.

Table 4 – Security Risk Ranking Matrix

Exploitability	Severity (Patient Safety / Business Impact)
	S1	S2	S3	S4	S5
Very Easy	Low	Moderate	High	Very High	Very High
Easy	Low	Moderate	High	High	Very High
Average	Low	Moderate	Moderate	High	High
Difficult	Very Low	Low	Moderate	Moderate	High
Near Impossible	Very Low	Low	Low	Moderate	Moderate

Once the security risk assessment is compiled, the risk rankings can be used to further focus on the highest risk areas collectively to determine if further controls should be considered
FDA guidance identifies the following standard control categories⁷:

• Authentication
• Authorization
• Cryptography
• Code, Data, and Execution Integrity
• Confidentiality
• Event Detection and Logging
• Resiliency and Recovery
• Firmware and Software Updates

Each control in the assessment should be assigned one of these control categories. This will allow all the controls to be reviewed to determine if certain categories may be missing from the assessment.

Finally, each control should be assigned a unique identifier in the assessment and traced to a requirement, design specification, or process specification. The requirements and specifications should be further traced to a test or inspection This trace matrix can then be used to demonstrate that all security controls have been implemented and tested

Review and Maintenance

• Are there any uncontrolled high-risk vulnerabilities?
• Do the highest risk items seem logical?
• Are there any risks that would be expected to be higher risk that are absent from the filtered list?

Make a pareto of risk both pre- and post-control.

• Is there a significant reduction in risk overall due to the security controls?
• Filter for risks with no security controls.

Are there any risks that should be controlled that are not?

• A new vulnerability is reported in off-the-shelf software used in the product.
• A customer reports a security event that impacts the product use.
• A similar product has a publicized vulnerability that is applicable.
• Product changes are made that may introduce new vulnerabilities and potential vulnerabilities

Ownership of the security risk assessment should be well defined within the organization. A process should be defined for how these triggering events are communicated to the owner to ensure that the security risk profile for the product remains acceptable. A cadence of periodic review of the security risk assessment should also be established to holistically review the overall security risk for the product

Conclusion

Creating and maintaining a security risk assessment can be challenging. By following the tips and guidance provided, this challenge can be lessened. More importantly, these tips and guidance will help ensure that the product security risk is appropriately characterized and controlled to enable the development and distribution of a safe and successful product.

References

---

Brett Todd is a Systems Engineering Director at Full Spectrum. Brett has been developing medical products for 29 years while serving in various technical roles including software developer, lead systems designer, and project manager He is passionate about product safety, well-defined requirements, and carefully considered architecture (his tenets of good medical product design) You can contact Brett at [email protected].